home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / C++ AppleLink Messages / CPlus.Dev$ 5⁄11⁄90 / 0126-Pointers from Hell-May90 < prev    next >
Encoding:
Text File  |  1990-05-11  |  1.9 KB  |  44 lines  |  [TEXT/GEOL]
  1. Item    2801205                         11-May-90        16:14PDT
  2.  
  3. From:   D4202                           HLH Assoc, Seth Haberman,PRT
  4.  
  5. To:     CPLUS.DEV$                      C++ Interest List--Developers
  6.  
  7. Sub:    Pointers from Hell
  8.  
  9.  
  10.  
  11.     To the c++ population:
  12.  
  13.  
  14.         I have been doing some c++ programming in windows for the ibm (ugh) and
  15. will start programming on the mac to make the product available for both
  16. machines.  Because windows uses a memory manager very similar to the macs I
  17. think this question will be relevant to both groups.  Basically, when one
  18. starts using either environment there is always the tremendous headache
  19. involving locked memory and movable memory blocks.  When some classes are
  20. created that don't have any likns then everything is kosher.  However, when
  21. even a simple thing like a linked list is attempted there has to be pointers
  22. to/from other objects.  Now when things are moving about in memory (which they
  23. should never do here), these objects have to be locked down so that all the
  24. pointers remain valid.  Is there a common way in the mac world for dealing with
  25. this situation.  Do you lock everything down (create a local heap) or is every
  26. pointer really a handle which gets double dereferenced.  (in the ibm world, the
  27. master pointer is actually returned to the user as an integer which then is
  28. locked with a call to:
  29.  void far *GlobalLock(Handle theInteger).)
  30. The latter method wastes quite a bit of time and space (double dereference for
  31. all! pointers, master pointers everywhere).  Is there a standard way of
  32. handling this in the (hopefully) nicer macintosh world?  Your ideas and
  33. suggestions will be greatly appreciated.
  34.  
  35.     Another question:
  36.         Is there a publication of the more advanced/esoteric c++ problems in
  37. the apple domain (i.e. constructing objects from the disk whilst they are of
  38. unknown type).
  39.  
  40.     - scot shinderman
  41.     - montage group, nyc.
  42.  
  43.  
  44.